1. Field of the Invention
The present invention relates to a transmission device equipped with Generalized Multiprotocol Label Switching (GMPLS) that allows automatic generation of transmission paths within networks, based on traffic transmission path generation instructions between any two nodes from an operator in a SONET/SDH network.
2. Description of the Related Art
At present, in order to reduce operating costs, GMPLS functions are provided in SONET/SDH transmission devices, and more and more transmission devices are equipped with extended functions, such as automatically configuring transmission paths (cross-connects) in devices, without performing manual configuration by administrators.
GMPLS in a SONET/SDH transmission device gathers adjacent information between nodes using Link Management Protocol LMP (RFC 4204), acquires network topology information using a routing protocol, such as Open Shortest First for Traffic Engineering—OSPF-TE (RFC 1850, RFC 3630), and then establishes a transmission path (cross-connect) using an arbitrary bandwidth between nodes according to a signaling protocol, such as Resource Reservation Protocol for Traffic Engineering-RSVP-TE (RFC 2205, RFC 3209, RFC 3473).
An example of an automatic setup of a transmission path will be shown. FIG. 1 shows a state in which transmission paths are generated connecting two locations by a network within a carrier network. When automatically establishing a transmission path between site α and site β of end user A in this type of network, the carrier network administrator provides instructions to generate a path for Node 1 with a bandwidth required between Node 6.
When this is done, the route for Node 1 will be calculated from the node itself to Node 6 from network topology information collected by a routing protocol.
FIG. 2 shows a state when using this route information to exchange signaling protocol control packets (using RSVP-TE in this example) from end-to-end to establish a cross-connect. The information exchanged here consists of PATH messages sent from Node 1, that received the transmission path generation instructions from the administrator, and RESV messages sent from Node 6, specified as a termination node.
The PATH messages include objects such as a session that indicates which node and port there is a link between, a PHOP (Previous HOP) that indicates which adjacent node the PATH message was sent from, a Label Request that indicates the existence of a path generation request (label request), an Explicit Route that shows the end-to-end route, a Session Attribute that shows the attributes of a session such as a connected session name, a Sender Template used to designate the node where the path generation was requested, a Sender Tspec that shows the bandwidth required for the path to be generated, and a Record Route used to record the PATH message relay route.
The PATH message relay node records each piece of this information and then transitions to a relay preparation state for a RESV message arriving later. The RESV message includes objects such as a Session that indicates which node and port there is a link between, a PHOP that indicates which adjacent node the RESV message was sent from, a Style that shows the style of the allocated bandwidth, FlowSpec that shows the bandwidth allocated to the transmission path, a Label allocated in order to generate the transmission path, and a Record used to record the RESV message relay route.
If Node 6, which received a PATH message, judges that the requested bandwidth is capable of being allocated and such operation is possible, the label for the transmission path (LSP) (for example, an object that can specify a SONET/SDH time slot) is extracted, a cross connection is established with the specified port in the requested bandwidth, and an RESV message, which includes the extracted label, is sent to adjacent Node 5 where the PATH message was sent.
Node 5, which received the RESV message, extracts the label used for the connection with Node 4, establishes a cross connection with the time slot specified by the label included in the RESV message, and then sends a RESV message to Node 4. Labels are distributed to each node between Node 1 and Node 6 by means of repeating this operation until reaching Node 1, and a transmission path is automatically generated.
When SONET/SDH performs time division multiplexing on traffic, the time slot (transmission path) that has a specified bandwidth linking two locations within the network by a point-to-point is secured, but all this bandwidth is used for the transmission of traffic between the two locations. When there is an increase in mutually communicating sites, transmission paths must be generated between each of two locations.
In contrast to this, when transmitting traffic forecast to have a statistical multiplexing effect, such as Ethernet® communication, sometimes it is preferable to share the transmission paths in order to efficiently utilize the bandwidth within the network when there is an increase in mutually communicating sites, if pre-established transmission paths exist on these routes.
In other words, this is a management technique that, for example, generates one transmission path as a backbone within the network and then shares this with multiple sites. Two types of reservation formats (styles) for sharing bandwidth are defined in RSVP-TE. If Wildcard Filtering (WF) is used from among these styles, the transmission paths can be shared (bandwidth sharing), although sharing according to WF does not distinguish the owners of the traffic being transmitted.
In other words, it is possible that different end users could share identical transmission paths. FIG. 3 shows a condition when end users who should not share are sharing paths. If a path is generated between sites γ and δ of end user B, where a transmission path already exists between sites α and β of end user A, and a WF style is indicated, the RSVP-TE will not differentiate between the end users. Because of this, the path used for end user A will form a path connection such that it is simultaneously used by end user B.
This is not a preferred situation because carriers who provide services which guaranty a certain bandwidth for each user as stated in the Service Level Agreement (SLA) contract might not be able to adhere to the SLA. In addition, if a Shared Explicit (SE) style is adopted, a Multi point-to-point connection can be specified explicitly. In other words, although it is possible to limit node groups which can share paths, this is done under the condition that the Explicit Route must be the same.
FIG. 4 shows a state in which a user transmission path desired to be shared cannot be shared. If a connection is made between sites ε and ζ of end user A, while there exists a transmission path between sites α and β of end user A and a transmission path between sites γ and δ of end user B, as the path used for end user A already exists, end user A will want to share this path. However, since the Explicit Route is different, it cannot be shared and a new path will be generated resulting in consumption of valuable network bandwidth.